Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-009

Text File | 1995-12-31 | 42.6 KB | 1,178 lines | [TEXT/R*ch]

Received-Date: Tue, 5 Apr 1994 15:00:22 +0200
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-009
To: [e-mail]
Date: Tue, 5 Apr 94 15:00:15 MET DST
X-Mailer: ELM [version 2.3 PL11]
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 11

C.S.M.P. Digest             Tue, 05 Apr 94       Volume 3 : Issue 9

Today's Topics:

        Better QuickTime play rates
        Debugging: when does an app start to execute?
        Full C++ Mac Framework wanted
        LISP on MAC
        MIDI Manager Source Example
        Making a font menu
        MoreFiles 1.1.1 - example file manager code
        NewGWorld - please help!
        Thread Manager 2.0



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Glen Lalonde)
Subject: Better QuickTime play rates
Date: 22 Mar 1994 14:24:34 GMT
Organization: IBM Toronto Lab.


I used a utility I wrote to see where time was being
spent while playing a rather large(13MB) 60second movie.
I found that about 50% of the machines time was spend in
one routine, this routine was in the system heap and
came from QT itself. It is 'cdec' number -16661,
function 'Anon 48' The loop at 'Anon48'+BA is taking
a LOT OF time. Anyone have any idea what this is doing?

Also, and possibly more important, is that 20% of the
machines time durring playback was spend in a ROM routine
called _SIntRemove. This routine is 0x29c4 long, ouch!
I read about it in IM V, but don't really see why it is
being used so much. Can some kind person tell me, or point
me, to why _SIntRemove is used at all durring movie
playback?(I have inside mac(old version) 1-6).

I assume you get:
QD call->8.24 card driver call->some kind of interrupt
gets generated?

I have a //si with 8.24 on the nubus card. Thanks.
My software inserts a VBL routine which inspects the
program counter, thus letting me profile the system.

Glen.


+++++++++++++++++++++++++++

>From [e-mail] (Jim Reekes)
Date: Tue, 22 Mar 1994 22:09:44 GMT
Organization: Apple Computer, Inc.

In article <2mmv32$[e-mail]>, [e-mail]
(Glen Lalonde) wrote:
>
>
> I used a utility I wrote to see where time was being
> spent while playing a rather large(13MB) 60second movie.
> I found that about 50% of the machines time was spend in
> one routine, this routine was in the system heap and
> came from QT itself. It is 'cdec' number -16661,
> function 'Anon 48' The loop at 'Anon48'+BA is taking
> a LOT OF time. Anyone have any idea what this is doing?

That's the image decompresser that draws the compressed video images to the
screen.

> Also, and possibly more important, is that 20% of the
> machines time durring playback was spend in a ROM routine
> called _SIntRemove. This routine is 0x29c4 long, ouch!
> I read about it in IM V, but don't really see why it is
> being used so much. Can some kind person tell me, or point
> me, to why _SIntRemove is used at all durring movie
> playback?(I have inside mac(old version) 1-6).

It's not really _SIntRemove. You have to know the exact address and the
look them up in the ROM maps. The bugger you are using is only reporting
the nearest trap in front of the address in ROM you are looking at. At that
location there are some VIA interrupt handlers, and below them are the SCSI
transfer routines.

> I assume you get:
> QD call->8.24 card driver call->some kind of interrupt
> gets generated?

> I have a //si with 8.24 on the nubus card. Thanks.
> My software inserts a VBL routine which inspects the
> program counter, thus letting me profile the system.

Then you should be using the ROM maps to get more accurate readings of the
ROM addresses.

- ---------------------------------------------------------------------
Jim Reekes, Polterzeitgeist   |     Macintosh Toolbox Engineering
                              |          Sound Manager Expert
Apple Computer, Inc.          | "All opinions expressed are mine, and do
20525 Mariani Ave. MS 302-3KS |   not necessarily represent those of my
Cupertino, CA 95014           |       employer, Apple Computer Inc."

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Tue, 22 Mar 1994 23:00:57 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Glen Lalonde) writes:
>I used a utility I wrote to see where time was being
>spent while playing a rather large(13MB) 60second movie.
>I found that about 50% of the machines time was spend in
>one routine, this routine was in the system heap and
>came from QT itself. It is 'cdec' number -16661,
>function 'Anon 48' The loop at 'Anon48'+BA is taking
>a LOT OF time. Anyone have any idea what this is doing?

The 'thng' resources specify that 'cdec' -16661 is the Cinepak
decompressor. What it is doing is left as an exercise
for the reader ;)

>Also, and possibly more important, is that 20% of the
>machines time durring playback was spend in a ROM routine
>called _SIntRemove. This routine is 0x29c4 long, ouch!

I'm not sure it's really in _SIntRemove. The symbol lists
for the ROMs are nowhere near complete, and registering
execution at _SIntRemove+$XXXX doesn't necessarily mean
it's stuck removing a slot interrupt. For example, the
*entire* memory manager is labeled as _StripAddress+$XXXX.
I could see it servicing a slot VBL call. Depending on the
machine you're using, I guess it could be processing async
disk I/O.

Hope this helps,

-Ivan
- -
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Anton Rang)
Date: 23 Mar 1994 00:32:46 GMT
Organization: Minnesota Angsters

In article <2mmv32$[e-mail]> [e-mail] (Glen Lalonde) writes:
>I found that about 50% of the machines time was spend in
>one routine, this routine was in the system heap and
>came from QT itself. It is 'cdec' number -16661,
>function 'Anon 48' The loop at 'Anon48'+BA is taking
>a LOT OF time. Anyone have any idea what this is doing?

  The 'cdec' resource is a compressor/decompressor.  Presumably the
loop you're looking at is handling picture decompression.

>Also, and possibly more important, is that 20% of the
>machines time durring playback was spend in a ROM routine
>called _SIntRemove. This routine is 0x29c4 long, ouch!

  Actually, no, that's not the routine.  It just looks like it because
it is followed by a huge amount of undocumented ROM code (well, not
undocumented exactly, just internal routines, not external traps.)
I'd have to look at the IIsi ROM map to be sure, but that's probably
either Sound Manager or QuickDraw code that you're seeing.
--
Anton Rang ([e-mail])


---------------------------

>From [e-mail] (Steven Lane)
Subject: Debugging: when does an app start to execute?
Date: Mon, 21 Mar 1994 00:20:31 GMT
Organization: University of Chicago

I figure there must be an easy answer to this, but I've had no luck
figuring it out. I want to set a breakpoint condition in MacsBug such
that I'll drop into the debugger sometime after _Launch, as soon as
the app's main code segment is entered. I've tried various things,
such as waiting until CurApName or TheZone changes, but these are
shots in the dark, given that I don't know how or in what order
_Launch does its business, and I don't enjoy ROM exploration in large
doses.

So: are there any decent rules of thumb on what conditions will true
at the point an app executes the first line of its own code? Any
pointers would be a big help. I'll be glad to summarize if there's
enough response or interest.


--
- --
Steve Lane
University of Chicago, Department of History
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chris Wysocki)
Date: Mon, 21 Mar 1994 04:08:06 GMT
Organization: Global Village Communication, Mountain View, CA

In article <[e-mail]> [e-mail] writes:

>I figure there must be an easy answer to this, but I've had no luck
>figuring it out. I want to set a breakpoint condition in MacsBug such
>that I'll drop into the debugger sometime after _Launch, as soon as
>the app's main code segment is entered.

For 68k applications, the easiest thing to do is set the low-memory
global LoadTrap (a byte at $12D) to non-zero before launching the
application.  This will cause _LoadSeg to drop you into Macsbug right
before RTS-ing to your code segment.  I haven't figured out how to do
the same thing for native applications, although I haven't had the
need to do this just yet....

Chris.

+++++++++++++++++++++++++++

>From [e-mail] (Steve Zellers)
Date: 21 Mar 1994 05:01:08 GMT
Organization: Berkeley Systems, Inc.

In article <[e-mail]>, [e-mail] (Chris
Wysocki) wrote:

> In article <[e-mail]> [e-mail] writes:
> For 68k applications, the easiest thing to do is set the low-memory
> global LoadTrap (a byte at $12D) to non-zero before launching the
> application.  This will cause _LoadSeg to drop you into Macsbug right
> before RTS-ing to your code segment.  I haven't figured out how to do
> the same thing for native applications, although I haven't had the
> need to do this just yet....

Holding down the control key when you launch your all will stop you in
__start, assuming you're using r2db & the debugger nub.  Not sure about
using the nub that comes with metrowerks, however.  (But if its
implementing the nub interface, it might just work.

--smz

--
Sr. Software Engineer
Berkeley Systems, Inc.

---------------------------

>From [e-mail] (Eric Krody)
Subject: Full C++ Mac Framework wanted
Date: 21 Mar 1994 15:14:49 GMT
Organization: Systems Research and Applications Corp., Fairfax VA


What does one do if one wants to write an application making full use
of C++?  Apparently, neither MacApp nor Symantec's Think Class Library
take full advantage of C++ (and TCL seems to be pretty far from doing
so given its heritage).  I read that QuickApp offers a framework written
in C++ but I don't know much about this Emergent Behavior product (nor
do I know anything about Emergent Behavior).  Any comments on what
direction to take?  Anyone used QuickApp? Anyone know Emergent Behavior's
phone number or have any other useful information?


+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 21 Mar 1994 10:34:31 -0800
Organization: Internet for the Olympic Peninsula

In article <2mkdl9$[e-mail]>, [e-mail] (Eric Krody) wrote:

>
> What does one do if one wants to write an application making full use
> of C++?  Apparently, neither MacApp nor Symantec's Think Class Library
> take full advantage of C++ (and TCL seems to be pretty far from doing
> so given its heritage).  I read that QuickApp offers a framework written
> in C++ but I don't know much about this Emergent Behavior product (nor
> do I know anything about Emergent Behavior).  Any comments on what
> direction to take?  Anyone used QuickApp? Anyone know Emergent Behavior's
> phone number or have any other useful information?
>

QuickApp is, er, quick.  [It was also recently incorporated into a new
Apple Developer University course which replaces two old object oriented
courses.  And it was incorporated into a course on OO for Taligent.]

A new QuickApp is coming "soon", which will be compilable using Metrowerks
CodeWarrior (including for Power Macintosh), and will support Apple events.
 Emergent Behavior is, among others, Dave Wilson (who has taught at Apple
Dev U for a LONG time, and is darn good), and Steve Wilson.
[e-mail]

CodeWarrior from Metrowerks includes the "PowerPlant" framework, which
looks promising.  CodeWarrior is currently out in its first developer
pre-release:  #2 is about to emerge.  68K only, PPC only, or both.
Delivered on CD.  I've already switched from Symantec (I wouldn't have for
an early deadline program, although some Power Macintosh code compiled by
CodeWarrior is already in service (Fetch 2.1.2, as one example).

I like the feel of the PowerPlant framework (by Gregory Dow of TCL fame).
It's "TCL done right given modern tools and a second chance" (my quote).

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

---------------------------

>From [e-mail] (Jason Strayer)
Subject: LISP on MAC
Date: 19 Mar 94 00:32:19 GMT
Organization: Georgia Institute of Technology


Anyone know of a good LISP compiler on Macintosh?
More importantly: a LISP compiler that is going to be released for the
PowerMACs?

Does such a thing exist?

thanks in advance,
jason


+++++++++++++++++++++++++++

>From Steve Bryan <[e-mail]>
Date: Sun, 20 Mar 1994 07:31:08 GMT
Organization: Sexton Software

In article <[e-mail]> Jason Strayer,
[e-mail] writes:
>Anyone know of a good LISP compiler on Macintosh?
>More importantly: a LISP compiler that is going to be released for the
>PowerMACs?

There's good news and bad news to report. A few years ago someone at
Apple liked a product called Coral Lisp so much that they bought the
company (product, developers, everything) and renamed it Macintosh Common
Lisp. This has been available for a few years as a $500 product from
APDA. It appears to have been rather actively supported by Apple as new
features have been added to system software with regular updates on the
developers' CDs. The bad news (if the $500 price tag wasn't already) is
that Apple appears to have narrowed its focus entirely to C++. The most
recent CD with issue 17 of develop has removed all updates to platforms
other than C++. I also read somewhere else on Usenet that Apple doesn't
have any plans currently to port MCL to the PowerPC.

If you don't mind entertaining rumors there is a Lisp like language
called Dylan that appears to have the strong support of Larry Tesler at
Apple that may be coming out yet. The most interesting rumor I read about
it is that Michael Kahl (developer of Lightspeed C, later called Think C,
recently called many other names) is working on the project.
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Frank Brickle)
Date: 20 Mar 1994 08:50:51 -0500
Organization: IDA - Center for Communications Research

>From article <[e-mail]>, by Steve Bryan <[e-mail]>:
> In article <[e-mail]> Jason Strayer,
> [e-mail] writes:
>>Anyone know of a good LISP compiler on Macintosh?
>>More importantly: a LISP compiler that is going to be released for the
>>PowerMACs?
>
> ...I also read somewhere else on Usenet that Apple doesn't
> have any plans currently to port MCL to the PowerPC.
>

Not exactly. What you probably read were furious postings *concluding*
(in spite of all public statements on the subject from people at
Apple) that MCL wouldn't be produced in a PPC-native version.

+++++++++++++++++++++++++++

>From Steven Ritter <[e-mail]>
Date: Sun, 20 Mar 1994 14:35:45 -0500
Organization: Psychology, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer: 20-Mar-94 Re: LISP on MAC
by Frank [e-mail].
> From article <[e-mail]>, by Steve Bryan
<[e-mail]
> .edu>:
> > In article <[e-mail]> Jason Strayer,
> > [e-mail] writes:
> >>Anyone know of a good LISP compiler on Macintosh?
> >>More importantly: a LISP compiler that is going to be released for the
> >>PowerMACs?
> >
> > ...I also read somewhere else on Usenet that Apple doesn't
> > have any plans currently to port MCL to the PowerPC.
> >
>
> Not exactly. What you probably read were furious postings *concluding*
> (in spite of all public statements on the subject from people at
> Apple) that MCL wouldn't be produced in a PPC-native version.

No, what he read was that Apple will not be producing a PPC-native
version of MCL. Apple is hoping to convince someone else to do the work
for them. This is basically what Rick Fleischman, the MCL product
manager, posted to comp.lang.lisp.mcl.

The general feeling is that the potential market for LISP is so small
that no third part could make a profit from MCL, and the fact that the
PowerPC is now out and Apple still hasn't found anyone to commit to
doing the port doesn't inspire much confidence that it'll get done at
all.

A surprisingly large percentage of AI researchers use Macintoshes
entirely because of MCL. These are not people who have any loyalty to
the hardware and if MCL doesn't keep up, they'll leave.

Steve


+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: Sun, 20 Mar 1994 21:51:09 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> Steven Ritter <[e-mail]> writes:
>Excerpts from netnews.comp.sys.mac.programmer: 20-Mar-94 Re: LISP on MAC
>by Frank [e-mail].
>> From article <[e-mail]>, by Steve Bryan
><[e-mail]
>> .edu>:
>> > In article <[e-mail]> Jason Strayer,
>> > [e-mail] writes:
>> >>Anyone know of a good LISP compiler on Macintosh?
>> >>More importantly: a LISP compiler that is going to be released for the
>> >>PowerMACs?
>> >
>> > ...I also read somewhere else on Usenet that Apple doesn't
>> > have any plans currently to port MCL to the PowerPC.
>> >
>>
>> Not exactly. What you probably read were furious postings *concluding*
>> (in spite of all public statements on the subject from people at
>> Apple) that MCL wouldn't be produced in a PPC-native version.
>
>No, what he read was that Apple will not be producing a PPC-native
>version of MCL. Apple is hoping to convince someone else to do the work
>for them. This is basically what Rick Fleischman, the MCL product
>manager, posted to comp.lang.lisp.mcl.
>
>The general feeling is that the potential market for LISP is so small
>that no third part could make a profit from MCL, and the fact that the
>PowerPC is now out and Apple still hasn't found anyone to commit to
>doing the port doesn't inspire much confidence that it'll get done at
>all.
>[...]


That will be a true bummer, then.  I know people who swear by MCL,
including one who feels it is the definative PC LISP implementation.
Plus it has (based on my limited experimentation) a very nice editor,
considering how long it's been around.

If I had need of a LISP environment, there would be no question of the
one I would buy.  From an aesthetic standpoint, this is nearly as bad as
Symantec not continuing THINK Pascal.  (Though I'm sure others will disagree
:-)

-H-


--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                             [e-mail]
                            Kill the Wabbit!

+++++++++++++++++++++++++++

>From [e-mail] (Frank Brickle)
Date: 20 Mar 1994 18:24:37 -0500
Organization: IDA - Center for Communications Research

>From article <[e-mail]>, by Steven Ritter <[e-mail]>:
>
> No, what he read was that Apple will not be producing a PPC-native
> version of MCL. Apple is hoping to convince someone else to do the work
> for them. This is basically what Rick Fleischman, the MCL product
> manager, posted to comp.lang.lisp.mcl.
>

I believe this is a pessimistic over-reading of Rick Fleischman's
postings.

+++++++++++++++++++++++++++

>From Malcolm Pradhan <[e-mail]>
Date: 21 Mar 1994 18:56:56 GMT
Organization: Section on Medical Informatics, Stanford University

In article <2milvl$[e-mail]> Frank Brickle,
[e-mail] writes:
> From article <[e-mail]>, by Steven Ritter
> <[e-mail]>:
> > No, what he read was that Apple will not be producing a PPC-native
> > version of MCL. Apple is hoping to convince someone else to do the
work
> > for them. This is basically what Rick Fleischman, the MCL product
> > manager, posted to comp.lang.lisp.mcl.
>
>  I believe this is a pessimistic over-reading of Rick Fleischman's
> postings.

 Not really. Fleischman said that further development on MCL would not
happen, implying that no new features would be added to the CommonLisp,
CLOS or interface framework.

What he did say was that bug fixes would continue, and they were looking
for a 3rd party to help them port the compiler to PowerPC. The reason
for the pessimistic tone is that Apple have been planning PowerPC for
years, but they have only just started to look at porting MCL. It's
good that they are trying to port at all it but the main reason for
doing so is that some of their internal projects (and one in
particular) use MCL as their compiler. My own hypothesis about the late
decision to port MCL is that it was deemed easier to find a 3rd party
to help with the port than it was to move the ATG project to Dylan.

 While MCL shouldn't be Apple's highest priority, I think their attitude
is symptomatic of their general disregard for Macintosh development, as
discussed by John Nagle in another thread.

 I like MCL a lot, and if you have a Mac and need a lisp I would
recommend it. But if you are looking for a lisp system with a future
then I could not recommend Mac Common Lisp, despite it being a great
lisp.

Interestingly enough, our lab would have purchased a number of 8100's
for Lisp development, and I would have upgraded my Mac straight away if
MCL were available. I'm sure Apple would have sold quite a few high-end
PowerPCs on the basis of the killer combination of the 601 + MCL.

 Regards,
 Malcolm

---------------------------

>From [e-mail] (Matti Lepist|)
Subject: MIDI Manager Source Example
Date: Mon, 21 Mar 1994 09:35:15 GMT
Organization: Ericsson Telecom

Hello!    :^)

Does anyone have a code example of how to use the MIDI manager
lib functions for mac.

I have tried to figure out how to do it by looking att the include file
MIDI.h and got som things working. But when I tried to write a
readHook and set it to a input port it crashes the MIDI manager when
I connect some output to it that generates MIDI events...

/Matti
_________________________________________________________________________

Matti Lepisto:                          Phone:             [phone]
Design Support                          Fax:               [phone]
TN/ETX/TX/DV                MiniCall:          [phone]
Ericsson Telecom AB                     E-Mail: [e-mail]
126 25 Stockholm, SWEDEN                Memo:             ERI.ETX.ETXLEPI
_________________________________________________________________________




+++++++++++++++++++++++++++

>From Paul Ferguson <[e-mail]>
Date: 21 Mar 1994 16:40:08 GMT
Organization: Kaleida Labs, Inc.

In article <[e-mail]> Matti Lepist|,
[e-mail] writes:
> Does anyone have a code example of how to use the MIDI manager
> lib functions for mac.
>...
> But when I tried to write a readHook and set it to a input
> port it crashes the MIDI manager when I connect some output
> to it that generates MIDI events...


Take a look at CMIDI, my MIDI Manager class library for THINK's TCL.
It includes a complete example program, Lefty, that you can
examine.  It's available by ftp from daemon.ncsa.uiuc.edu.

As for your readHook crashing, here are two possible causes:  not
declaring the readHook as a pascal function (if you are programming
in C), or violating restrictions on interrupt handlers if your
input port is set to process packets during interrupt time.

Also, if you are using THINK C, the MIDI.h file shipped with it is
WAY out of date, and is incompatible with CMIDI.

If you continue to have difficulties, I suggest getting the MIDI
Manager programmers kit from Apple ($35US).  It contains the latest
headers, detailed documentation, and several example applications
with full source code.

--fergy

- ------------------------------------------------------------------
  Paul Ferguson         | "It's a sick world, I'm a happy guy..."
  [e-mail] |
- ------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Mel Walker)
Date: Mon, 21 Mar 1994 18:44:01 GMT
Organization: Committee to Elect Dan Quayle Lord of the Cosmos

Paul Ferguson ([e-mail]) wrote:
: If you continue to have difficulties, I suggest getting the MIDI
: Manager programmers kit from Apple ($35US).  It contains the latest
: headers, detailed documentation, and several example applications
: with full source code.

Is buying the kit the only way to get the MIDI manager? Is it the
cheapest way?

--
Mel Walker                                         [e-mail]
"Natural exuberance is one of those qualities that makes us tigers so
darn endearing!" -- Hobbes

+++++++++++++++++++++++++++

>From [e-mail] (Howard Berkey)
Date: Mon, 21 Mar 1994 18:58:42 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <[e-mail]> [e-mail] (Mel Walker) writes:
>Paul Ferguson ([e-mail]) wrote:
>: If you continue to have difficulties, I suggest getting the MIDI
>: Manager programmers kit from Apple ($35US).  It contains the latest
>: headers, detailed documentation, and several example applications
>: with full source code.
>
>Is buying the kit the only way to get the MIDI manager? Is it the
>cheapest way?
>

I imagine you can get the Mgr. itself free with various software (I
think Master Tracks Pro 5 came with it), but then you don't get any
docs.

Does APDA sell anything CHEAPER than $35?  I seem to remember some
t-shirts and pens in the back of the catalog :-)

Seriously, the Midi Mgr. is one of the least-overpriced offerings from
APDA.  You get a pretty bad (IMHO) reference manual, some OK example hacks,
the MIDI mgr, and Patchbay (neat idea).  I haven't looked at in in a
year or so but I remember being more or less immediately able to write a
MIDI-driven graphics applet which would display variously sized and
located rectangles based on incoming MIDI information, so it was at
least SOME help :-)


-H-




--
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Howard Berkey                                             [e-mail]
                            Kill the Wabbit!

+++++++++++++++++++++++++++

>From Paul Ferguson <[e-mail]>
Date: 21 Mar 1994 19:34:44 GMT
Organization: Kaleida Labs, Inc.

In article <[e-mail]> Mel Walker,
[e-mail] writes:
> Is buying the kit the only way to get the MIDI manager? Is it the
> cheapest way?

For whatever reason, Apple has never freely distributed the
MIDI Manager as they do other System software extensions.
Some MIDI software manufacturers bundle the MIDI Manager
driver and PatchBay software.

For programming, the MIDI Manager developer kit includes the
drivers, PatchBay, programmer's documentation, source code
examples, etc.

BTW, the MIDI Manager will probably disappear soon, with its
functionality rolled into QuickTime 2.0.  Apple never really
supported the MIDI Manager very well; I hope that MIDI will
get more "respect" as part of QT.

--fergy

- ------------------------------------------------------------------
  Paul Ferguson         | "It's a sick world, I'm a happy guy..."
  [e-mail] |
- ------------------------------------------------------------------

---------------------------

>From [e-mail] (David Blume)
Subject: Making a font menu
Date: Sat, 19 Mar 1994 02:26:04 GMT
Organization: Gokuraku Videos - Wollongong Dept.

How do you determine which fonts are available in the system software to
add them to a menu?  (Ie., how do you get a valid list of font names or
font numbers for use with GetFontName() or GetFNum()?)

Thanks,
--David
+---------------------------------------------------------------+
|  David Blume    |  "I get tired thinking of all the things I  |
|  [e-mail]  |   don't want to do."  --Bukowski, _Barfly_  |
+---------------------------------------------------------------+

+++++++++++++++++++++++++++

>From [e-mail] (MarkHanrek)
Date: 19 Mar 1994 06:17:02 -0500
Organization: America Online, Inc. (1-800-827-6364)

I don't remember where I saw the example source code. Probably on the Developer
CD.

But look through the technotes, because I remember reading that we need to be
careful how we do this, because if we do it the obvious way, :), then we will
end up loading all the fonts we have into the system heap and the size of the
system partition will mushroom like you wouldn't believe.

The appropriate method was given for doing this, so the technotes may be a
place to look next.  Also, I may have seen something in  d e v e l o p.

Hope this helps.

Mark Hanrek


+++++++++++++++++++++++++++

>From [e-mail] (Peter Mattis)
Date: 20 Mar 1994 22:02:47 GMT
Organization: Computer Science Undergrad Assoc., UCBerkeley

The way I remember doing this was a simple call like this:

AddResMenu(myMenu, 'FONT');

(I think 'FONT' is right, but don't quote me on it).

This should append all the fonts available in the system to myMenu.
Then when a user selects a font you can find its fontID based on its
location in the menu (since the fonts will be in alphabetical order in
the menu).

If this isn't enough, e-mail me and I'll send some C source I have
for making a font menu and selecting a font from it.

-Peter Mattis

+++++++++++++++++++++++++++

>From Doug Eernisse <[e-mail]>
Date: 21 Mar 1994 02:42:13 GMT
Organization: University of Michigan - College of Literature, Science, and TheArts

In article <2mih67$[e-mail]>
Peter Mattis, [e-mail] writes:

>AddResMenu(myMenu, 'FONT');
>
>(I think 'FONT' is right, but don't quote me on it).
>
>This should append all the fonts available in the system to myMenu.
>Then when a user selects a font you can find its fontID based on its
>location in the menu (since the fonts will be in alphabetical order in
>the menu).

Does anyone have advice on a fairly direct way to only list fonts
that are nonproportional fonts? This is for a special purpose
application where the columns have to line up, so a proportional
font doesn't work properly.


Doug

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Mon, 21 Mar 1994 17:23:49 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

On ftp ftp.cso.uiuc.edu, there ar 24 C "disks" (files) and one of them
has the source for an Ascii program.  There are actually two ascii
sources on that ftp - one is for a DA, which I've updated, and added an
application version and posted on a.s.m.  It merely has the "charts" in
the source, all laid out in a table, and "DrawStrings" them to the window.

But the OTHER one in a regular ascii chart application, and it gets the
characters from the keymap and puts them in a grid - just like the modern
ascii chart programs (DA's) do (not as well done, thought).  It's got one
font menu, and a size menu.  You select a font in the font menu and that
fontName is now the title of the size menu.

This old source does NOT compile and run as-is.  I've got my copy to do
so and will post it as soon as it runs *right*, but in the mean time you
could get that source and look at those menu routines and it may help, in
addition to the fine advice earlier in this thread.

Connect to the ftp, then it's "cd mac/MUG", then "get C2.cpt.Hqx".

The file is in the SuMac folder.

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Mon, 21 Mar 1994 17:26:00 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

By the way, there's another old source i've updated to run on Think C
called "Font Show" which is on a.s.m, and their ftp, which may help.

-Ken-

+++++++++++++++++++++++++++

>From Reid Ellis <[e-mail]>
Date: Tue, 22 Mar 1994 22:08:31 GMT
Organization: Alias Research, Inc., Toronto ON Canada

Peter Mattis <[e-mail]> writes:
|AddResMenu(myMenu, 'FONT');
|
|This should append all the fonts available in the system to myMenu.
|Then when a user selects a font you can find its fontID based on its
|location in the menu (since the fonts will be in alphabetical order in
|the menu).

Well, close.  You find its font id by calling GetFNum() on the string
in the menu item selected by the user, not by its position in the
menu.

If you want a subset, like proportional fonts or PostScript fonts, you
have to walk the menu, deleting any items that don't match your
requirements.

Reid

P.S.  How about AddResMenu(menu, 'FOND')?
--
- -
Reid Ellis, Alias Research Inc.
[phone] <[e-mail]>

---------------------------

>From [e-mail] (Brian Bechtel)
Subject: MoreFiles 1.1.1 - example file manager code
Date: 22 Mar 1994 07:37:32 -0800
Organization: Apple Computer, Inc., Cupertino, California

MoreFiles 1.1.1 is available for anonymous ftp from the site
ftp.apple.com (130.43.2.3) in the path:
  /dts/mac/sc/morefiles1.1.1.hqx
I take it this would be a URL of
  ftp://ftp.apple.com/dts/mac/sc/morefiles1.1.1.hqx

MoreFiles, by Jim Luther of DTS, is sample code showing how to do most
of the things people ask about doing with the Macintosh file manager.
In my opinion, it's very well written and valuable code.

--Brian Bechtel     [e-mail]     "My opinion, not Apple's"

---------------------------

>From [e-mail] (Volkan Can)
Subject: NewGWorld - please help!
Date: 20 Mar 1994 15:10:25 GMT
Organization: UMass-Lowell Computer Science

Hello, I'm trying to make a program I'm writing, draw to an offscreen gworld..
for the life of me, I can't figure out what I am doing wrong..

when I use copybits to copy the data from the from the offscreen gworld to my
window, I get garbage in my window...

I drew a line offscreen and it was there but I also got a lot of other garbage.
(After te copybits that is)
Is some other application writing to this offscreen memory?

Can someone explain to me when and where I should use the keeplocal and/or no
new device or even the purge? flag with NewGWorld?

please help..

also, I am setting the size of the gworld to the size of my window
and the orig and dest rect's in copy bits are the same (same size as window)

please leave email to me..
vc



+++++++++++++++++++++++++++

>From [e-mail] (Alex Metcalf)
Date: Sun, 20 Mar 1994 17:06:09 GMT
Organization: Demon Internet

In article <2mhp11$[e-mail]>, [e-mail] (Volkan Can)
wrote:

> Hello, I'm trying to make a program I'm writing, draw to an offscreen gworld..
> for the life of me, I can't figure out what I am doing wrong..
>
> when I use copybits to copy the data from the from the offscreen gworld to my
> window, I get garbage in my window...

     Usually the problem is that people don't send dereference the GWorld
correctly. Here's an example of the sort of call you want to use:

CopyBits ((BitMap *) *myGWorld, (BitMap *) &gGameWindow->portPixMap,
     &myRect, &myRect, srcCopy, nil);

     Notice the dereference of the world, and sending the pointer of the
window's pixmap.

> Can someone explain to me when and where I should use the keeplocal and/or no
> new device or even the purge? flag with NewGWorld?

     Don't bother using the keeplocal thing, and setting it to purge just
causes extra work for you. The "no new device" option removes the problems
with matching colour tables. Best thing to do is read Inside Mac 6: it's
called something like the "Graphics Devices" chapter. At least, it's the
one before the Sound Chapter.

     Hope this helps,


     Alex

+++++++++++++++++++++++++++

>From [e-mail] (ScottSquir)
Date: 21 Mar 1994 01:42:04 -0500
Organization: America Online, Inc. (1-800-827-6364)

(Volkan Can) writes:
>when I use copybits to copy the data from the from the offscreen gworld to >my
window, I get garbage in my window...

>I drew a line offscreen and it was there but I also got a lot of other
>garbage.
>(After te copybits that is)
>Is some other application writing to this offscreen memory?

Make sure you erase your GWorld first.  Just use EraseRect(&theRect) before
actually drawing to the GWorld.   The GWorld is just memory and NewGWorld
doesn't do anything except allocate it and setup the structures.
-scott


+++++++++++++++++++++++++++

>From [e-mail] (MarkHanrek)
Date: 21 Mar 1994 12:36:03 -0500
Organization: America Online, Inc. (1-800-827-6364)

Because todays information management is still primitive, we are lead to
believe that all we need to do is use the NewGWorld call and we're ready to go.
I did.

But here is the basic NewGWorld routine I have come to use, which does all the
required things that we learn about as we go along. Hopefully this will save
you and others from a lot of wasted time.

Hope this helps.

Mark Hanrek

- ----------------------------------------------------------------

Notes:

The statements marked with //** are the important ones that we
find out the hard way are the additional things we must do
before we consider a GWorld fully prepared.

The "tryTempMem" parameter allows you to easily specify if its
okay for the routine to try to allocate the GWorld in MultiFinder
temporary memory.  This is handy, for example, when allocating an
intermediate GWorld for dithering from 32-bit to 8-bit color, which
is only needed momentarily and will be gone before the user gets
back control.  Once allocated, work with it and dispose of it
normally.

You could change the behavior of this parameter to force using
temporary memory in the first place, and backing off to application
memory, an improvement I just realized would be nice as I sit here
typing this. :)

When you read in pictures destined for a GWorld, get the picture's
colors first, and then feed the color table to this routine when
creating its GWorld, then draw the picture into the GWorld.

Feel free to redesign the parameters and convenience features of
this routine to suit your taste. The important thing is that our
GWorlds must be clipped, erased, and have their coloring set
straight before we continue on our way.


//****************************************************************

OSErr CreateNewGWorld( Rect *theRect, short theDepth,
             CTabHandle theColors, GWorldPtr *theGWorld, Boolean tryTempMem )
{
  CGrafPtr    previousGW;
  GDHandle    previousGD;
  QDErr       err;
  GWorldFlags theFlags;
  RGBColor    rgbOpColor = { 0x8000, 0x8000, 0x8000 };
  RGBColor    rgbBlack   = { 0x0000, 0x0000, 0x0000 };
  RGBColor    rgbWhite   = { 0xFFFF, 0xFFFF, 0xFFFF };

  GetGWorld( &previousGW, &previousGD );

  if (( err = NewGWorld( theGWorld, theDepth, theRect, theColors, nil, 0L )) !=
noErr)
    if ( tryTempMem == true ) {
      if (( err = NewGWorld( theGWorld, theDepth, theRect, theColors, nil,
useTempMem)) != noErr)
        return( err );
    } else
        return( err );

  SetGWorld( *theGWorld, nil );

  ClipRect( &(**theGWorld).portRect ); //**

  if ( LockPixels( GetGWorldPixMap( *theGWorld )))
  {
    RGBForeColor( &rgbBlack );    //**
    RGBBackColor( &rgbWhite );    //**
    OpColor( &rgbOpColor );       //**

    EraseRect( &(**theGWorld).portRect );

    UnlockPixels( GetGWorldPixMap( *theGWorld ));
  }

  SetGWorld( previousGW, previousGD );
  return( err );
}


---------------------------

>From [e-mail] (Bill Lipa)
Subject: Thread Manager 2.0
Date: 21 Mar 1994 06:29:24 GMT
Organization: Center for Advanced Medical Informatics at Stanford


The PowerMac compatible version of the Thread Manager is included in the
April developer mailing. Upon reading the documentation, I was surprised
to find out that preemptive threads are not supported on PowerMacs. Does
this really mean that any program that uses preemptive threads is not
portable to the new machines?

I wonder why they had to make this change.

Bill Lipa
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Leonard Rosenthol)
Date: Mon, 21 Mar 1994 21:03:15 GMT
Organization: Aladdin Systems, Inc.

In article <2mjes4$[e-mail]>, [e-mail] (Bill
Lipa) wrote:

> The PowerMac compatible version of the Thread Manager is included in the
> April developer mailing. Upon reading the documentation, I was surprised
> to find out that preemptive threads are not supported on PowerMacs. Does
> this really mean that any program that uses preemptive threads is not
> portable to the new machines?
>
> I wonder why they had to make this change.
>
   It has to do with the way the 68000 interrupt system works on the
PowerMac.  There is not a multi-level interrupt scheme, as I understand
it, so they can't easily schedule the interrupts they way they do on the
68K.

Leonard
- ------------------------------------------------------------------------
Leonard Rosenthol                      Internet:       [e-mail]
Director of Advanced Technology        AppleLink:      MACgician
Aladdin Systems, Inc.                  GEnie:          MACgician

---------------------------

End of C.S.M.P. Digest
**********************